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NETWORK TRAFFIC CONTROL IN PEER-TO-PEER ENVIRONMENTS 



TECHNICAL FIELD 

5 

The present invention relates to a network traffic control unit, a network comprising such a 
network traffic control unit, a method for controlling traffic on a network, and to a 
corresponding computer program product. 

10 

BACKGROUND OF THE INVENTION 

Peer-to-peer applications become more and more popular since a wide range of data stored on 
computers on the edge of the Internet can now be accessed. Computers that stored and 
15 provided data only for local access and in addition provided means for retrieving data from 
Internet servers may serve today as a data base for other computers and simultaneously may 
receive data not only from Internet servers but also from other remote computers when 
executing peer-to-peer applications. This widens the pool of accessible data tremendously. 

* 

20 Below, the term peer or node or peer node is used for an electronic device - for example a 
computer, a workstation or a PDA (personal digital assistant) but not limited to - that can run 
a peer-to-peer application. Therefore, such node should be able to access a network in order to 
exchange information with other nodes. 

25 Gnutella is currently one of the most prominent representative of unstructured peer-to-peer 
applications. These applications are called unstructured as nodes peer with other nodes 
in a random fashion. Searching in unstructured peer-to-peer network essentially 
is a random probing as resources such as files or other services are made available on arbitrary 
nodes in the network. The main advantages of these systems are their simplicity, for example 

30 the protocols used are very simple, and their dynamics in a sense that nodes can 

appear and disappear at a high rate. Another advantage is that search queries can be almost 
arbitrary complex and includes keyword-searching, substring-matching etc 
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Peer-to-peer applications that include file exchange protocols - like Gnutella - Gnu V0.4 
dvnaniically establish an "overlay" network to exchange information. When a peer is started, 
it tries to peer with other peers using a request/accept protocol. The requesting peer sends a 
5 "connect request" to another peer node. If this other peer authorizes the connection it answers 
with a "connect accept" and the two parties establish a adjacency. Then they can start 
exchanging information that get passed on to other peere. 

FIG. 1 Illustrates the way connectivity is achieved within an exemplary network comprising at 
10 least two peer groups 1 and 2 - also called clusters. Each peer group 1 or 2 comprises peer 
nodes A. B, C, respectively D and E. Reference 3 indicates some physical interconnection 
(wire-bound; wireless) between peer groups 1 and 2. Arrows Indicate an already established 
peering connection which is rather a logical interconnection than a physical interconnection. 
Such connection is established by having one of the peers send a connect request message to 
15 the other peer and the other peer having accepted this connect request message with an accept 
message according to the protocol of the peer-to-pcer application. 

In FIG. la), node C is peered with nodes A and B, as well as node D is peered with node E. 
Nodes C and P are prone to peering as C gets to know about D. Therefore C sends a connect 
20 request to D and D accepts by sending an accept message back to C 

According FIG. lb), C and Dare now peered and C relays messages to D, the messages issued 
by A and B, whereas D relays messages to C, the messages issued by E. In the following, A 
and D would like to peer as A gets to know about D. Therefore A sends a connect request to D 
25 and D accepts by sending an accept message back to A 

According to FIG. Ic), A and D are now peered in addition to the already existing peering 
connections. However, there are now two logical peering connections existing on the physical 
interconnecting link 3. These two logical connections were established by means of at least 
30 four messages crossing the interconnection 3. 
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This overlay network - thai is a term for the network of logical connections - is an ad-hoc 
network that does not rely on an infrastructure. One well-known problem is how to bootstrap 
the peering mechanism, that is how a peer can find addresses of other peers to peer with. 
Usually two types of techniques are used to solve this problem. One solution consists of the 
5 peer connecting to a server located at a well-known address. This server maintains a list of 
peers' addresses that are communicated to the peer. Another solution is for the peer to 
maintain itself a list of other peer it peered with and use addresses from this list 



In account of the technique, peering is done based on a list of addresses without taking into 
10 the actual network infrastructure or the affinity between peers. Therefore the resulting overlay 
network is typically totally de-correlated from the physical network. This can lead to a very 
inefficient use of the network resources and poor performances of the file search protocol 
using this network. 

15 Another example shown in Figure 2 demonstrates an example how a physical network is 
flooded with peer-to-peer application messages in order to establish adjacencies between peer 
nodes. Three clusters 1, 2, 4 are shown. Big circles represent physical network nodes (e.g. 
routers, gateways), whereas small circles represent peer nodes. Dotted lines represent physical 
interconnections between physical network nodes, whereas straight lines represent logical 

20 interconnections between peer nodes. As can be derived from FIG. 2, peer node A is 

communicating with peer node F only via peer nodes 3 to E, while they are adjacent in the 
physical network. Note that in this example links joining cluster 1 to cluster 2 and cluster 1 to 
cluster 3 will easily get congested. 



25 Structure of peer-to-peer applications thus result in a limited scalability due to brute-force 
flooding and a clear misfit of the overlay network topology with the underlying Internet 
topology representing ehe physical connections. 



30 



Flooding the underlying physical network with messages is not only a problem when looking 
for other peers to peer with but also when querying for information, such as data files, once an 
overlay network is established. 
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HG. 3 introduces such exemplary query process according to the protocol of a peer-to-peer 
application: HG. 3a) is similar to FIG. la) and shows Ac establishment of a peering 
connection between nodes C and D. 

5 

According to FIG. 3b), node A now issues a query request "Looking for vivaldi.mp3", C 
forwards this query request to B and D, D forwards this request to D. Arrows between two 
peer nodes pointing only in one direction indicate the transmitted query requests. 

10 E is supposed to have what A is looking for, so E sends a confirmation message to D, see HG. 
3c). D knows that the confirmation is related to a request corning from C so sends the 
confirmation message to C. C knows that the confirmation message is related to a request 
coming from A so sends the confirmation message to A. Then, A contacts E using other 
means, ag. HTTP, to get the file. 

15 

Several approaches to limit peer-to-peer traffic were introduced that are highly structured. 
These approaches tightly control how and on which nodes information is stored. Also, peering 
of nodes is not random and the resulting overlay networks are often congruent to the 
underlying Internet topology. The disadvantage is that these approaches do not cope well with 
20 very high dynamics, i.e, a rapidly changing user population makes these systems unstable. 
Furthermore, these systems excel in exact-match queries but have some weaknesses in 
key-word based queries and substring queries. 

Therefore, it is desired to have network traffic controlling means provided while having peers 
25 causing such traffic remaining unchanged. 



SUMMARY OF THE INVENTION 

30 According to one aspect of the invention, there is provided a network traffic control unit, 
comprising a filter unit for intercepting messages from a network line. Messages are 
intercepted relating to peer-to-peer application irrespective of the de$tination of a message. 
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There is further provided a control logic that is configured for managing a request represented 
by an intercepted message, subject to its content and subject to peering specific knowledge the 
network traffic control unit provides. 

5 According to another aspect of the invention there is provided a method for controlling traffic 
on a network, comprising receiving messages relating to peer-to-peer application, intercepted 
by a filter unit from a network line, irrespective of the messages' destination, and managing a 
request represented by an intercepted message, subject to its content and subject to peering 
specific information. 

10 

The filter unit filters messages that indicate in one way or another that they are peer-to-peer 
application related. Peer-to-peer applications typically enable user computers to act as both 
client and server for data files or services to other user computers. In a preferred embodiment, 
the filter unit is checking port fields of TCP messages with regard to appearance of defined 

15 port numbers in designated port fields that indicate peer-to-peer application. A peer-to-peer 
application might use a port number to be identified that is different to the port number of 
other peer-to-peer applications, and different to port numbers of other non peer-to-peer 
applications. However, other significant information of a message might be used to filter 
peer-to-peer application related messages. The network traffic control unit and its filter unit 

20 might be prepared to filter and then to control only messages related to a certain peer-to-peer 
application or might be prepared to filter and then to control messages of different known 
peer-to-peer applications. Messages not relating to a peer-lo-peer application are typically not 
affected and can pass the filter unit unhampercdly. 



25 The filter unit thus intercepts peer-to-peer application traffic on a network line irrespective of 
the destination of the messages. The traffic that is filtered is thus not directed to the IP or 
whatever address of the network traffic control unit but typically addressed to peer 
destinations. Nevertheless, the network traffic control unit is intercepting this kind of traffic in 
order to get control on it 

30 

In order to achieve extended control on peer-to-peer traffic on a network, it is considered to be 
preferred to give the network traffic control unit access to a network line that is carrying large 
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amounts of such traffic. A preferred network line to be accessed by the filter unit is an 
ingress/egress line to a group or cluster of peers, such that all or most of network traffic to or 
from peers of this clusters has to pass this network line and can be monitored. 



5 On a lower level of a hierarchical communication layer, a message is represented by one or 
more data packets as indicated above when talking about TCP protocol. Other protocols of 
course may be used instead. The filter unit might be embodied as packet filtering logic 
implemented on a network processor. Since the network traffic control unit and the associated 
proposed method have to primarily manage requests from peers, it is in particular appreciated 

10 to detect such requests. This detection can be implemented by the filter unit: For example, a 
request might be expressed in the corresponding data packet with a defined code in a 
designated field of the data packet Then, the filter unit can be prepared to check this field for 
a given number of codes representing a request. Other peer-to-peer application messages may 
also be filtered but treated differently from a management point of view than requests. 

15 Alternatively, messages comprising peer-to-peer application requests might be delected by 
intercepting peer-to-peer application messages by means of the filter unit and having a 
command field of such messages analyzed by the control logic. 



The control logic may be implemented in hardware or software or a combination thereof, or 
20 any other suitable implementation. A task that is assigned to the control logic is to manage 
requests that are intercepted. Managing comprises, that such requests are now handled by the 
control logic in a way that might be different to the way the request pertaining peer-to-peer 
application envisages, but also satisfies the requesting peer, thereby preferably causing less 
traffic on the network than the peer-to-peer application would cause. The network traffic 
25 control unit therefore might preferably set up new messages, redirect requests, interact with 
the requesting peer or peers intercepted messages are addressed to or even other netwodc 
traffic control units. These are only some actions a network traffic control unit could provide, 
but not necessarily has to provide all of them. The opportunities for managing requests are on 
the other hand not limited to the enumerated actions. 

30 

Basically the control logic discovers the content of such intercepted message and coordinates 
measures to satisfy the needs expressed by such message dependent on the content of the 



message and dependent on knowledge the network control unit has, either stored in a memory 
or by way of accessing other sources of knowledge. This knowledge is peering specific 
knowledge that helps in taking measures to satisfy queries, connect requests or other requests 
more efficiently. Typically, peers by themselves do not have this knowledge available, 

5 

Thus, the invention allows the dramatic reduction of network traffic caused by peer-to-peer 
applications by installing a network traffic control unit that takes the lead in managing 
requests intercepted from a network line. Adding such smart control creates benefits in 
controlling and limiting peer-to-peer application initiated traffic. This can be achieved without 
10 changing or amending neither participating peers nor the network structure and even without 
making the introduction of such a network traffic control unit public with the peers or other 
entities within the network. The topology of the peer-to-peer overlay network is enhanced. 
Network control units can be added or removed without any requiring any changes to the 
peers* 

15 

The network traffic control unit can a stand alone electronic device in one preferred 
embodiment. In another preferred embodiment, the functions of the network traffic control are 
added to the functions of a router, such that only one device is responsible for both, router and 
traffic control functions. 

20 

According to many of the preferred embodiments introduced below, the control logic is 
sending messages in order to manage requests. This has to be interpreted such that the control 
logic primarily decides on sending messages, while the physical transmission of messages is 
initiated by an interface that is controlled by the control logic. 

25 

In a preferred embodiment, the intercepted message is dropped. This step is performed after 
having the content of the message evaluated. Dropping the intercepted message expresses that 
the control logic takes control for further managing and thinking about new ways to handle the 
request This is a first traffic limiting effort 

30 

Preferably, a request to be managed is a connect request issued from a peer node and directed 
to another peer node. Such connect request is sent in order lo establish a connection to another 
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* peer, that may provide the contacting peer with ihe information or service the contacting peer 
looks for after it accepted such connect request, li is important to have connect requests 
handled by the control logic of the network traffic control unit, since such connect requests 
might cause many other succeeding connect requests between other peers, for example when 
5 the peer-to-peer application determines to have a connected peer send connect requests to 
other peers he is aware of. By managinjg such connect requests and thus controlling actions for 
satisfying these requests, the flood of peer-to-pcer traffic can be contained dramatically. 

A preferred way to manage a connect request is to handle further actions with regard to 
10 already existing connections the network traffic control unit is involved in. Whenever a peer is 
requesting connectivity to a another peer, and the requesting peer is already connected to a 
third peer, preferably of the sariie remote cluster, the network traffic control unit might desist 
from sending a new request to this cluster, especially When it Ls aware that the other peer is 
already connected to the requesting peer via the third peer. 

fix a preferred embodiment, thenetworicjtraffic control unit therefore provides peering specific 

knowledge information on peer-to-peet -connections the network traffic control unit is 

currently aware of. ' 

: ! : 
t • 

20 As indicated above, preferably no message might be sent to the addressee of the intercepted 
connect request when a connection is already established that can serve the requesting peer 
node. ^ i • 

In another preferred embodiment, the control logic initiates sending a connect request to the 
25 originator of the intercepted connect request in response to the intercepted connect request. 
This is to folly get control on thl handling of the intercepted connect request. The network 
traffic control unit sends this connect request with its own ID as originator. In the following, 
the requesting peer exclusively communicates to the network traffic control unit Traffic can 
be controlled and limited effectively. • V 



30 



Where appropriate, the network (traffic control unit sends a connect request with its own ID as 

".is! 

originator to the addressee of the intercepted connect request. This might be reasonable in 

; : M 

■ If : • 

ii : 
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order to satisfy the needs of the requeuing peer as long as there is no other connection 
established in particular to this peer c$n general to this cluster. When there is a connection to 
another peer of this remote cluster, the network traffic control unit might prefer using the 
existing connection to reach the requested peer instead of fulfilling the original request to 

5 connect. , 

. • its 

• ! :: 

In another preferred embodiment, thef^etwork traffic control unit sends a connect request to 
the addressee of the intercepted cowiejdi request, thereby pretending the originator of the 
intercepted connect request is sendingj&e connect request This is an alternative method of 
10 controlling the establishment of connections, when the network traffic control unit is not 
appearing under its own identity. ! ';> 

\* 

It may be preferred, sending a conrtectirequest to a peer node other than the addressee of the 
intercepted connect request in responsfcjlo the intercepted connect request This other peer 
15 node might support establishing a connection to the requesting peer node. There might be 
different reasons and strategies, when aionnect request is redirected by the network traffic 
control unit. Typically, the network trajf&c control unit acts under its own identity when 
redirecting a connect request • I 

20 Especially when a connect request is directed to a peer of another remote cluster and another 



network traffic control unit is allocated to this cluster, it is preferred mat the local network 
traffic control unit exclusively "talks" fojpcers of the other cluster? via the remote network 
traffic control unit This limits liuffic drastically. Such a connect request to another network 
traffic control unit might also be advantageous in order to receive peering specific information 
25 the othar network traffic control;unit provides in preparation of connecting peers of the remote 
cluster. 



When the network traffic control unit isj flitercepting a connect request and acting in the 
following under its own identity! further^actions might be preferably initiated only after the 
30 originator of the intercepted connect request accepts the connect request that is sent to him 
from the network traffic control fonit lis prevents generating traffic, when the originator i 



not prepared to communicate with the ri 



ork traffic control unit 



©016 
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Especially for managing connect requests described above, the network traffic control logic 
preferably prepared to communicate According to a protocol of the peer-to-peer application. 



5 Other requests that am preferably hanjfied by the network traffic control unit axe data file 
queries issued by a peer node Jnd bron|ht to the attention of the network traffic control unit 
by way of filtering. These querjv requests cause lots of succeeding traffic cither, such that 
effective management of handling sucttrequests is vital for reducing overall peer-to-peer 
induced traffic on the network.] Typica^y, a query request is sent after peers are connected in 
10 order to figure out which of these onli£ p eers can provide the information the queryingpeer 
is looking for. i :<i 



In a preferred embodiment, managing Uch a query request is subject to an index that allocates 
keys representing data files for jfownkjad or representing services to network traffic control 
15 units. This index is considered j* peering specific knowledge. A key specifies at least a part of 
the content of a certain query and is generated from the content of the respective query request 
according to fixed rules that the contro&ogic preferably implements. Having such a key 
derived from the query reque 5 t,jthe network traffic control unit derives from this index, which 
network traffic control unit among sorrjl or many network traffic control units is responsible 
20 for administering information ok this kgr. This information then maps peer nodes to keys. The 
mapped peer nodes are currently registered for providing a file the key stands for 

; i«i 

ir 

In a preferred einbodiment of the invention, the peering specific knowledge a network traffic 
control unit provides comprises ;an inde^ that allocates keys representing data files for 

25 download to network traffic control <m& This index is preferably locally stored in every 
network traffic control unit and fcistrmu&d regularly, respectively updated on a regular or 
event driven basis. Every network taa^icontrol unit is responsible for administering 
information related to a number jbfkey^ As keys in the end represent information on queries 
and especially on queried data files, eve# network traffic control unit administers information 

30 on a number of different data files. Such|nforrnation, collected in another index then allocates 
peer nodes to keys, giving thus detailed |iformation which peer actually can provide a certain 
data file. j, ijj 

: t 
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Since looking for a file or a service c& be expressed in queries in many different ways by 
different strings, the search strings of jc pery requests are not very suitable for executing the 
query request immediately. Thereforef jit is preferred, that one or more keys are derived from 
5 the content of the query request - thatjl particularly a string. The underlying set of rules is 



preferably stored by the network trafGcjcontrol unit; its control logic is configured for 



implementing such rules for deriving leeys from query requests 

Ml ' 

"When such key or keys are derived frejA a query string by means of the control logic, and 
10 when a network traffic control unit thai administers die keys is found by screening the 

corresponding index, a requestlis dhedted to one or more remote network traffic control units 
that are allocated to the derived keys in-order to obtain information which peers have the files 
represented by me keys available. Theirequested network traffic control unit or units 
preferably send such information back : |o the requesting network traffic control unit A hit 
15 message from the network traffic control unit to the querying peer node might then be 
preferred for having the peer node selejqt any number of data files offered. Many preferred 
variations of this process are introducea jlater on. 



Pi 

ij 

Some network traffic control units me^efore provide preferably a key -peer node index for 
20 some keys. These network traffic control units provide other network traffic control units with 
the knowledge which peer node* are ali|cated to a requested key according to the key - peer 

* r til 

node index. Administration tas^s of such a network traffic control unit preferably include 
updating the index by adding anid remojtjjng entries. 

f i| 

25 In another preferred embodiment, a way ! bf updating indexes of peering specific knowledge is 
introduced: Hit messages sent fijbm apter node associated to the network traffic control unit 



are monitored. One or more keys are d«|ved from the content of a hit message. The sending 
peer node is allocated to the derived ke$s, and the key - peer node relation is stored in the key 
- peer node index at the networtftraffic jJimtrol unit that administers the index the key is part 
30 of. This method helps to keep peering specific knowledge up-to-date. 
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Preferably, such advanced seach incHding underlying communication between network 
traffic control unit as well as akminis||ing indexes, tables or other peering specific 
knowledge is accomplished using a p$tocol different to the peer-to-peer application protocol. 
Such protocol is more efficient and a^ses the above mentioned purposes. This protocol is 
5 specifically used for managing query requests 

r i • 

For many purposes, it is preferred to have peering specific knowledge available that comprises 
information on peer nodes associated td the network traffic control unit. This helps optimizing 
managing efforts as peer nodes of a joUt cluster are typically located close to each other. Such 
10 distance information might affect managing requests by the network traffic control unit. 

Ij 

jlj : 

According to another aspect of the motion, mere is provided a network comprising at least 
one group of peer nodes, a network linje serving as ingress/egress line for this peer group, and 
a network traffic control unit accordinfeljto any one of claims referring to such unit. 



if! 

According to another aspect of he invUtion, there is provided a computer program element 
comprising computer program i ©de wh|bh, when loaded in a processor unit of a network 
traffic control unit, configures the prori|sor unit for performing a method as claimed in any 
one of the method claims. 

Advantages of the different aspects of & e invention and their embodiments go along with the 
advantages of the inventive network trifle control unit and method described above. 



25 BRIEF DESCRIPTION OF TjHE DRAWINGS 

The invention and its embodiments will jbe more fully appreciated by reference to the 
following detailed description ollpresenW preferred but nonetheless illustrative embodiments 
in accordance with the present mventioijwben Taken in conjunction with the accompanying 
30 drawings. ! 



The figures are illustrating: 



@ois 
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FIG. 1, a known way of establishing jjeer-to-pccr connections over a network, 
FIG- 2, a symbolic diagram of a network showing connections established according to a 



5 known peer-to-peer application, 



if 



FIG. 3, a known way of querying inf< 



brih; 



nation according to a known peer4o-peer application, 
, in accordance with an embodiment of the present 
traffic control unit, in accordance with an 



FIG. 4 a), a diagram showing a netwoj 
10 invention, 

HG. 4 b), a block diagram of a netwoijlj 
embodiment of the present invention, 
FIG 4 c), a flow chart of a method for jsbntrolling traffic on a network, in accordance with an 



embodiment of the present invention, , r 



15 



FIG 5, a diagram showing the way messages are exchanged, in accordance with an 



embodiment of the present invention, 

HG. 6, a way of establishing peer-to-pi 
20 embodiment of the present invention, 

FIG. 7, another way of establishing pe 



t connections over a network, in accordance with an 



to-peer connections over a network, in accordance 



with an embodiment of the present invej tion, 



25 FIG. 8, a symbolic diagram of a netwc 
an embodiment of the present inventior 

FIG. 9, a block diagram of a network, : 
invention, 



30 



FIG. 10, a data structure a network traffji 

i 

in accordance with an embodiment of 

S 



showing connections established, in accordance with 



accordance with an embodiment of the present 

i 

t 



control unit provides as peering specific knowledge, 
present invention, 



8 

PIG. 11, a flow chart showing a searclf|for data files or services, in accordance with an 
embodiment of the present invention, 

j 

5 FIG, 12, a flow chart showing a methol I for updating peering specific knowledge. 

.\ 
•P 

• c 

Different figures may contain identicaljjUferences, representing elements with similar or 
uniform content 



10 



DETAILED DESCRIPTION OF THE DRAWINGS 



I 



FIG. 4 shows embodiments of different!; aspects of the present invention. FIG* 4a) illustrates a 
chart of a network in accordance with embodiment of the present invention, FIG. 4 b) a 
15 block diagram of a network traffic contt ol unit in accordance with an embodiment of the 
present invention, and FIG 4 c) a flow 'i lart of a method of controlling traffic in accordance 

i I \ 

with an embodiment of the present invaj ition. j 

J i 

FIG. 4 a) shows two clusters 1 and 2. TE e cluster* 1 an & 2 are physically connected via an 
20 interconnection 3. Cluster 1 comprises Some routers lOjand an edge router 1 1 being the router 
that is directly connected to the intercotmection line 3 -;aIso called network line 3. Neither are 
shown the peers belonging to each clusters nor any Jogipal connections between peers. 



A network traffic control unit 5 - also q&led booster - ii introduced in the network co-located 

id j 

25 with the network ingress/egress node - tnat is the edge iputcr 1 1 in order to control at least a 

l\ 1 

laige part of the traffic the cluster 1 is transmitting and receiving. This traffic is present on the 
network line 3, 



FIG. 4b) shows a block diagram of the pfkwork traffic control unit 5. The network traffic 
30 control unit 5 comprises a filter unit 5 1 ,* feeing implemented in a network processor. The filter 
unit 51 is monitoring the network line 3 and filters all messages on this network line 3 that 



relate to peer-to-peer applications. Othe 



messages - res] 



>ectively the corresponding data 



15/11 '02 FR 16:43 FA^£ 1 724 89 51 



further comprises!* control 



packets - are not affected, and take the i 
traffic control unit 5 
and also has capability to 
A memory 53 is provided for storing pi iej 



5 to. 



way to destination on network line 3.- The network 
logic 52 that receives intercepted messages 
send respectively initiate sending messages over the network line 3. 

ring specific knowledge the control logic has access 



FIG. 4 c) shows a flow chart of the 
messages that are sent the over netwotj 
connect request sent from a peer of clu| cer 
10 establishment of the overlay network to 
thereby enhancing the performances 
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the network traffic control unit 5 is having impact on 
line 3, and especially to messages that represent a 

1. Overall principle here is controlling the 
pology by the network traffic control unit 5 and 
e protocol. 



The basic principle is to intercept peer- >»peer connect requests issued by cluster 1 peers and 
to force the requesting peer to peer wiflj the network traffic control unit 5. The interception is 
15 performed by the filer unit 51. Only the network traffic control unit 5 peers with external peers 
and if necessary relays protocol messag issued by the peers located inside the network cluster 
L Whenever control logic 52 rakes the I edsion that according to the content of the 
intercepted request - that might be the J quest from peer X to connect to peer Y - and 
according to peering specific knowledgl - that might be the information, that peer X is already 
20 connected to peer Y via another peer of he same cluster - the intercepted packet is dropped 
and no finther action is required. This d Jistically limits the traffic on the ingress/egress link 
and allows the protocol to scale. 



FIG. 5 shows the protocol exchanges I 
25 how the booster peers with the 

Booster 5 intercepts since a peer-to-peer 
addressee, and content of the message 



to the interception of the connect request and 
peer. Peer A sends a connect request to peerB. 
plication message is detected. Originators address, 
it is a connect request - are extracted. Then the 
connect request in dropped. Booster 5 tfa in issues a connect request under its own identity to 
the peer A who is going to accept it as it 




30 



The booster 5 then might peer with exte 
extended using sophisticated informatic 



i looking for peer nodes. 

al peers or other boosters. This scheme can be 
exchanges among boosters to enhance the protocol's 



@02 
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perfonnances. For example, sumrnarie; ; 
generated using distributed hash tables 



of files available in the booster's network can be 
(e.g.CAN/Chord or Fastiy/Tapestry). 



respectively D 



i connection 



FIG. 6 shows a diagram explaining the 
5 embodiment of the present invention. I 
exemplary network comprising at least 
comprises peer nodes A, B, C, 
between peer groups 1 and 2. Arrows 
established peering connection which is 
10 physical interconnection. Such 

connect request message to the other 
request message with an 
application. 

15 In FIG. 6a), node C is already peered with nodes A and B, as well as node D is peered with 
node E. Nodes C and D are prone to pee ring as C gets to know about D. Therefore C sends a 
connect request to D. Such messages an indicated by an arrow pointing from the originator to 
the addressee. Li the charts, only the originator of a message is indicated verbally in brackets. 
But the real message also contains the ic entification of the addressee. 



way messages are exchanged in accordance with an 
is illustrated how connectivity is achieved within an 
two peer groups 1 and 2. Each peer group 1 and 2 
and E. Reference 3 indicates a network line 
pointing in two directions indicate an already 
rather a logical interconnection based on some 
is established by having one of the peers sent a 
the other peer having accepted this connect 
to the protocol of the peer-to-peer 



peer and 1 



20 



control unit 5. Its information/content is 
25 traffic control unit 5 takes full control ou 



30 



A network traffic control unit 5 accordii] g to an embodiment of the invention is introduced. 
The identifier of the network traffic con! rol unit 5 is "G* It filters messages of peer-to-peer 
applications. Thus, the connect requestf rom C to D is intercepted by the network traffic 

extracted and the request is dropped. Now, network 
managing further actions in response to the 
intercepted connect request to fulfill the keeds of C: It therefore sends a connect request to C. 
C accepts. According to peering specific knowledge the network traffic control unit 5 has 
access to, it is still necessary to contact I ». Therefore, network traffic control unit 5 sends a 
connect request to D containing its identi fier G. D accepts. 

According to FIG. 6b), C and G arc pee* d now as well as G and D are. Now A and D would 
like to peer as A gets to know about D. Therefore A sends a connect request to D that is 
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intercepted by G = network traffic conftol 
message's content. G sends a 



i connect request 



further 



There is no need for establishing a 
5 already connected to D and A is connected 
no further action and in particular doesjaot 
contacts D another time. According to. 
D, or G and D as a result. Thus, traffic 



unit 5. The request is dropped after extracting the 
to A. A accepts. 



logical connection between A and D since C is 
to C. Thus, the network traffic control unit 5 takes 
send the connect request from A further or 
Ij\IG. 6c) r there is no further connection between A and 
limited. 



10 HG. 7 shows basically an alternative tb FIG. 5 with regard to the way messages are 

exchanged. HG. 7 illustrates the same.ii etwork with the same elements as HG. 6. The way the 
network traffic control unit 5 managesi itercepted connect requests is now different: The 
netwoifc traffic control unit 5 does not a jpear under its own identity but manipulates in a more 
hidden way. Connect requests are still h itercepted and dropped. After having evaluated 

15 peering specific knowledge and the coni em of the message, it might still be reasonable for 
network traffic control unit 5 to contact D. But now, D is approached with a connect requests 
that looks like the original one sent by C , showing C as originator instead of G. The accept 
message from D is also intercepted and iin identical accept message is forwarded to C by the 
network traffic control unit 5. This ineth od is shown in HG. 7a). HG 7 b) illustrates the actual 

20 connections of the overlay network after wards. 



HG. 8 illustrates a diagram of a network 
known network according to HG. 2, no\ r 
ingress/egress nodes. They are exclusive y responsible foj 
25 which is indicated by straight lines. As 
connection between network traffic cont|ol 
which reduces traffic tremendously. Alsc 
cluster 1. This knowledge was provided 
while establishing connections and 



) managing 



' unstructured . peer 



The scalability problems of 
addition to be alleviated by replacing the 



as an embodiment of the invention. Compared to the 
network traffic control units 5 are installed at 

>r establishing the overlay network 
be derived from the diagram, there is only one 
unite 5 of different clusters 1, 2, 4 established 
, peer A can now peer with peer F via peer B within 
imd applied by the network traffic control units 5 
intercepted connect requests. 



-to-peer approaches can alternatively or in 
brute-force searching (querying) with an intelligent 
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data location mechanism. Thus, "the network traffic control unit provides managing 
capabilities for managing query requests that ate intercepted and analyzed. Again, the peers 
can remain unchanged whereas in the-'core of the network an advanced location mechanism is 
used. HG. 9 shows a network according to an embodiment of the invention. The peers that are 
5 located within three peer groups 1, 2 and 4 are all named as Gnutella Peers, as in this 
embodiment the traffic related to Gnutella peer-to-peer application should be managed. The 
network traffic control units 5 are located such that each network traffic control unit 5 is 
associated with a peer group such that a network traffic control unit 5 has access to all sent or 
received messages the peers of his group are involved in when communicating to peers of 
10 other peer groups. With regard to physical network topology, network traffic control units 
typically sit between access and edge routers such that they may intercept peer-to-peer 
messages. Like this, a network traffic control unit serves a number of peers in its vicinity to 
which it is network close. ' 

15 Among the network traffic control units; 5 and especially for managing intercepted query 
requests in an intelligent low-traffic way, a protocol different to the peer-to-peer protocol is 
used in order to better match these new requirements. Such protocol may be named 
"Advanced Search and Location Protocol". The advantages of this approach are: In the core of 
the network, flooding is replaced by a scalable advanced location mechanism. This improves 

20 scalability and significantly reduces the iunount of control traffic. The peers do not have to be 
replaced or changed. In particular, a highly dynamic peer population is supported. The 
network traffic control units 5 are relatively stable and thus fulfill the requirements of 
structured peer-to-peer systems. They protect the network from flooding messages and use an 
advanced location mechanism instead. • ' 

25 ■[ 

In the following, the architecture is explained using the Gnutella protocol as an example for a 
peer-to-peer application protocol. Other unstructured peer-to-peer approaches work similarly. 
The peers execute the Gnutella protocol to locate files and execute HTTP to download files. 
Network traffic control units also implement the Gnutella protocol in order to communicate 
30 with the peers. Unlike standard peers, network traffic control units do not participate in 
flooding Gnutella requests. Between network traffic control units, an advanced location 
mechanism is used. 



A part of the control logic managing capabilities is preferably the application of a set of rales 
for translating the content of queries - iad especially the strings of such queries representing 
the content - into keys. Keys are more«asy to query and less vague in representing a statement 

! 

5 than language is. In addition, keys areanoro short than strings and therefore need less 
bandwidth. ! ! 

A given input string is first processed by a stop-word filter that removes all words that are 
insignificant for the search, A parser tEten generates a set of hash-codes - that are regarded as 
10 special implementation of keys using lash-functions - from the remaining words of the query. 
In the most simple case, the parser generates a single hash-code from each word. A 

sophisticated parser maps content to a hierarchical structure, for instance 

.t 

filetype = M music" 

15 .format = "mp3 ,T 

iakist^'vivaldT 
conductor = "karajan" 

■ ; 

! i 

and allocates a key to this structure. S 

For each valid sub string of a query, additional keys might be computed. This allows to 
implement sub string queries. Details ofcjbow this could be achieved are described in "A 
Scalable Peer-to-Peer Architect ure fort&tentional Resource Discovery" by Magdalena 
Balazinska, et aL, Pervasive 2002 - Iht&iiational Conference on Pervasive Computing, August 
25 2002, which is hereby incorporated by reference. 

i j 

The resulting keys are used to retrieve information from a distributed key - peer index. The 
key - peer index is distributed among neOvork traffic control units in a way that eveiy network 
traffic control unit maintains only a pact jof the overall key - peer index. A single network 
30 traffic control unit is administering a lirhited number of keys. Such key - peer index maps 
peers that store the file the key is related to. 



JLl 



FIG. 10 illustrates data structure of sujeka key - peer index stored on a single network traffic 
control unit. The network traffic contibl unit keeps a fraction of the overall distributed key - 
peer index. A given key maps to nonefpne or more filenames and the corresponding file is 
stored on one or several peers. 



Basic logic of managing queries that is implemented in the control logic of a network traffic 
control unit includes preferably: 



:.l 



For a given key, the control logic locates the network traf fic control unit on which more 
10 information associated with mis key are stored. There is preferably an index or a function 
available mapping keys to network traffic control units. A key and its associated information - 
especially peer and filename, and possMly the network traffic control unit that is associated to 
the peer - might be stored on multiple network traffic control units. In this case, the control 
logic locates the one which is closest tbjthe requesting network traffic control unit The key - 
15 network traffic control unit index is dynamic in the sense that new network traffic control 
units can be added and existing ones can be removed. Compared to the change rate of the 
peers, the change rate of the network bjaffic control units is expected two of magnitude lower. 

J 

The result of a key query is a list of fueijames which are then returned to the peer that 
20 originally issued the query. Optionally &ese filenames may be compared by the network 
traffic control unit against the filename^ jextracted from the original query in order to produce 
a ranking list, which is then returned to'Ae peer. Also, due to the inherent nature of generating 
keys and especially hashing there is alwiys a non-null chance of two different inputs being 
mapped into the same key. This also mjgfct cause preference to double check, e.g. by way of 
25 comparing original filename and returned filename. 

P 

FIG. 1 1 illustrates a flow chart of mana|jng a query request triggered by a peer that sends a 
query message 100. The network traffid«ontrol unit might be a peer and therefore receives the 
message or alternatively intercepts the ijiaessage by diverting peer-to-peer traffic - here 
30 Gnutella traffic - from the network, jfi 



l\ 



The network traffic control unit then prgciceds as follows: 



m 

t! 



It computes a set of hash codes 103 bised on the search string. For each valid sub string, a 
hash code 15 computed, too. This allows to implement sub string queries. Stop-word filter and 
name parser techniques are applied Regenerating the hash-codes, step 101, 102. These steps 
5 can of course have different order. • 

V - 

The network traffic control unit locates the destinations in terms of other network traffic 

M 

control units where the derived bash-dddes /keys are administered. This is achieved by means 
of a key - network traffic control unit index. A query message for the computed keys is sent 
10 from the managing network traffic control unit to the discovered remote network traffic 
control units. Upon reception of such message, me remote network traffic control unit will 
return values associated with the queried key, step 104. These values comprise of a list of 
Peers that store the requested file. Fo^each peer, the associated network traffic control unit is 
also listed. 



15 



Whenever the specific keys are stored bn the managing network traffic control unit, there is of 
course no need for contacting other network traffic control units and the peers that are 
associated to the queried keys can be djetected on the local network traffic control unit. 



f • 

r 



20 The returned keys might be translated Into strings and be compared to the original query string 
sent by the requesting peer, step 105. f ; 

V 

If the list is not empty, then the inanagtog network traffic control unit returns a hit message to 
the querying peer and gives itself as source, step 106. A peer might then be free to chose 
25 among the returned filenames and select any number of diem for retrieval. 

■ t - 

If either a push request or a HTTP get jfequest arrives at the network traffic control unit, then 
the network traffic control unit selects flhe real data source - i.e. a specific peer - to retrieve the 
file from. As selection criteria itmay uie the quality of the netwoik connection (delay, 
30 throughput, error rate, or other parameters that might be evaluated by the network traffic 
control units) and freshness of informafion. Tne network connection for retrieving is not 
offered to the offering peer but instead to its associated netwoik traffic control unit, as the two 
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network traffic control units are assuifced to ; bc correlated. In locality-aware DHTs, evaluation 
of the network connection is delivered without any additional overhead. 



After the serving peer is chosen, the 
5 the file from this peer via the associate id 
it to the querying peer. 



managing network traffic control unit starts retrieving 
? network traffic control unit, then directly forwarding 



In case an entiy is not available - that inight 
disappeared or no longer has this file 
10 executed to disseminate this new infomnatioh 
the managing network traffic control 
the next best - offering peer instead, oi 



mean the peer that was listed as offering a file has 
Jin explicit removal procedure as described below is 

to the other network traffic control units. Also, 
£t may decide to retrieve from another - for example 
idirectly notifying the querying peer of the failed 



unit 



15 PIG. 12 depicts a flow chart for an i 
that are forwarded through the 
an network traffic control unit. 



insert 



networikfThe -insert 



As soon as a network traffic control 
20 application protocol that originates 

key - peer index has to be performed adifollows: 



The network traffic control unit compu 
200. This computation is analogous to 
25 is computed, the managing control 
administering this key. If that key is 
traffic control units. The 
together with the filename, the address 
network traffic control uniL 



administering aetwoik 



30 



t operation that is based on monitoring hit messages 
method is managed by the control logic of 



tin ft; observes a hit answer according to the peer-to-peer 
froibonebf its local peers a new entry in the distributed 



N s a 5et ^ keys, step 201, 202 based on the filename 
i be one used for the search operation. For each key ihat 
logi jr identifies a network traffic control unit that is 
nof existing yet, it is assigned to one of the network 
traffic control units then stores the key 



if the jpeer as well as the IP address of the associated 



* 

re raove operation that also updates tHpjkey I- peer index can include of an implicit and / or 
explicit part. Implicit removals occur i/|n index entry wasn't accessed for some time. Time 
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outs are expected to be in the range of ime or more hours. implicit removals are done by each 
network traffic control unit individual by periodically checking entries that have timed out. 
Explicit removals occur when a download from an index entry did not succeed either because 
the file ox the peer has disappeared, hi &is cjase, the index entry is removed on all network 
5 traffic control units that store the asso rfated:key. 
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CLAIMS 



, comprising 
* intercepting tn eksages 



10 



5 1. Network traffic control unit, 
• a filter unit (51) fori 

• relating to peer-to-peer apfjlication, 

• from a network line (3), 

• irrespective of destination, 
a control logic (52) that is configuj 
message subject to its content and 
traffic control unit (5) provides. 



for managing a request represented by an intercepted 
habject to peering .specific knowledge the network 



2. Network traffic control unit accordi 
15 wherein the network traffic control uni : 
peer-to-peer application protocol. 



iiiigto claim 1„ 
: p) is prepared to communicate according to a 



prdiig 



3. Network traffic control unit accoi 
wherein the network traffic control uni 
20 protocol for managing connect requests, f 



25 



4. Network traffic control unit accordii g 
wherein the network traffic control uni ; 
protocol different to the peer-to-peer aj pjli 



ardiri % 



5. Network traffic control unit accoj 
wherein the network traffic control unit 
peer-to-peer application protocol for 



30 6. Network traffic control unit accordin 
wherein the peering specific knowledge 
the network traffic control unit (5) is cu npntty 
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to claim 2, 

: (5) is prepared to apply the peer-to-peer application 



to any one of the claims 1 to 3, 
' 5) is prepared to communicate according to a 
ication protocol. 



to claim 4, 

(|5) is : prepared to apply the protocol different to the 
query requests. 



managing! 



to any one of the preceding claims, 
;compirises information on peer-ro-peer connections 
aware of. 
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7. Network traffic control unit accord ng to jany one of the preceding claims, 
wherein the peering specific knowled je comprises information on peer nodes associated to the 
network traffic control unit (5). 

8. Network traffic control unit accoriU ag to kny one of the preceding claims, 



data files for download to network traffic control units. 



10 9. Network traffic control unit according to any one of the preceding claims, 



wherein the peering specific knowled§ e 
representing data files for download. 



from intercepted query requests. 



20 network line (3), irrespective of tta 



comprises an index that allocates keys representing 



comprises an index that allocates peer nodes to keys 



10. Network traffic control unit accorc ing tojany one of the preceding claims, 
15 wherein the control logic (53) is configured for implementing a set of rules for deriving keys 



i 



1 1. Method for controlling traffic on a network, comprising: 

i 

• receiving messages related to peer- ;o-peejr application, intercepted by a filter unit from a 



messages' destination, 



• managing a request represented by an intercepted message subject to its content and 
subject to peering specific informal ion, j 

12. Method according to claim 1 1, coniprisinjg 
25 dropping the intercepted message. 

13, Method according to claim 1 1 or cltem 12, 



30 



wherein a request to be managed is a cc 
another peer node. 

14. Method according to claim 13, 



nnect request issued from a peer node and directed to 
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wherein managing the connect reques t 
control unit is aware of. 



15. Method according to claim 14, 
5 wherein no message is sent to the addkssee 
connection is already established lhat pan selve 
node. 
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subject to existing connections the network traffic 



1 6. Method according to any one of th e claii as 13 to 15, comprising 
10 sending a connect request to the origidator o F the intercepted connect request in response to 



the intercepted connect request. 

17, Method according to one of the clz ims 
; a connect request to the addressee 




©033 



26. 



of the intercepted connect request when a 
or be extended to serve the requesting peer 



15 



18. Method according to one of the claims 1$ 
sending a connect request to the addrei see of 
originator of die intercepted connect re quest 



20 19. Method according to one of the cla tins V: l 

sending a connect request to a peer noqe other than 
request 



20. Method according to one of the claims 12 
25 sending a connect request to another network} traffic 



21. Method according to claim 16 in cdmbin4tion 
sending the connect request to another ?arty 
request once the originator has accepts I the 
30 unit directed to the originator. 



22. Method according to any one of the prece iing claims ! 1 to 21, 



lp, 14 or 16, comprising 
of the intercepted connect request. 



, 14 or 16, comprising 

the intercepted connect request pretending the 
is sending the connect request. 



to 16, comprising 

the addressee of the intercepted connect 



to 16, comprising 

control unit (5). 



with any one of the claims 17 to 20, 
than the originator of the intercepted connect 
c onnect request from the network traffic control 
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wherein a request to be managed is a 



23. Method according to claim 22. 
wherein managing the query request 
5 files for download to network traffic 




lata fi le query issued by a peer node. 



subji ct to an index that allocates keys representing data 
cbntrol units. 



10 25. Method according to any one of th^ 
deriving one or more keys from the 



content 



26. Method according to claim 25, coqtprisi^g 
directing a request to one or more 
15 derived keys according to the key 



24. Method according to claim 22 or c l!aim : 3, 

wherein managing the query request is ■subject to an index thai allocates peer nodes to keys. 



claii as 22 to 24. comprising 
of the query request. 



i remote 



net work 



rte ne work traffic control units that are allocated to the 
raffle control unit index. 



20 



27, Method according to claim 26, con ijprisiiig 

receiving a list of peer nodes that are allocate d to the keys, from the remote network traffic 
control unit 

28. Method according to claim 27, ronbrisiik 
sending a hit message to the querying deer n< >de. 



29. Method according to any one of th 
25 • administering a key - peer node indpx for 
• providing other network traffic control 
nodes are allocated to a requested 



preedding claims 1 1 to 28, comprising 
some keys, and 
iu|its on request with the knowledge which peer 
according to the key - peer node index. 



30. Method according to claim 29, 
30 wherein administering the key - peer ncjde inefcex comprises removals of entries. 

31. Method according to any one of thaprece ling claims 1 1 to 30, comprising 
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monitoring hit messages sent fron 
deriving one or moie keys from 
allocating the sending peer node 
storing the key - peer node relatioA 



the 



to. 



15 



32. 



10 



A network comprising 
at least one group (1, 2, 4) of peer Jiodes 
a network line (3) serving as 
a netwoik traffic control unit (5) 
intercepting messages from the 



ss line for this peer group (1, 2, 4), and 
ateordihg to any one of the preceding claims 1 to 10, 
she. 



nei work 



33. A computer program element 
processor unit of a network traffic 
method as claimed in any one of claimls 



com msing computer 



con rol 
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an as sociated peer node, 
conl ent of a hit message, 
the c erived keys, and 
in a J fey - : peer node index. 



program code which, when loaded in a 
m it, configures the processor unit for performing a 
lltu31. 
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di sclose tffor controlling 1 



A«lter 



A method and an electronic unit are 
for controlling peer-to-peer related traffic, 
peer-to-peer application from a netwoi fc line 
control logic then manages a request n spresefitedlby 
10 content and subject to peering specific infon iiation. 




traffic on a network, especially 
uitit is intercepting messages related to 
irrespective of the messages 7 destination, A 
an intercepted message subject to its 
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Booster S" 
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Client B 



iMeroejptjon 
Originator's address extraction 



Coniwaion Raqueu(B,A) 



Coaoectian Accept (A3) 



1 

Request discarded 
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cousin Of several ^Wla 
amoves useteaa worts 

translates lmo chunk* 
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This Page is Inserted by IFW Indexing and Scanning 
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BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SL ANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



